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FOREWORD 

This  report  represents  work  performed  by  the  Management  Science 
and  Statistics  Department  of  the  University  of  Alabama,  University, 
Alabama,  while  under  contract  to  the  Ballistic  Missile  Defense  Advanced 
Technology  Center.  Technical  contact  for  this  effort  was  Mr.  Walter  L. 
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ABSTRACT 

This  technical  report  describes  a  microprocessor  version  of  a 
threat  allocation  model  based  on  simple  decision  heuristics.  Model 
capability  is  demonstrated  by  allocating  a  threat  composed  of  four 

cTP&tZtriM 

j  r.v.  systems  over  four  categories  of  assets  using  different  asset 

defense  schemes.  Allocations  obtained  with  the  heuristic  model  compare 
favorably  with  allocations  obtained  with  a  much  more  sophisticated 
model . 

The  report  also  describes  a  generalized  R&D  project  network 
simulation  model  which  provides  reliable  estimates  for  project  start 
and  completion  times,  project  duration  times,  and  failure  statistics. 
The  simulation  model  is  demonstrated  with  a  complex  network  composed 
of  six  individual,  interdependent  projects. 

The  report  includes  as  an  appendix  a  paper  describing  a 
mathematical  optimization  approach  to  threat  allocation  decisions  .that 
was  presented  at  the  national  ORSA/TIMS  meetings  in  October  1982. 
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SECTION  I 


INTRODUCTION 

The  research  described  in  this  report  was  conducted  as  three 
separate  projects  and  is  reported  here  in  separate  sections.  A  major 
emphasis  of  the  research  was  to  develop  a  simple,  heuristic  algorithm 
for  the  threat  allocation  decision  which  could  be  executed  on  a  micro¬ 
processor;  the  results  of  this  effort  are  described  in  Section  II.  A 
secondary  emphasis  of  the  research  was  to  develop  a  generalized  R&D 
network  simulator  for  use  in  project  planning  and  management;  results 
of  this  phase  of  the  effort  are  described  in  Section  III.  Finally,  a 
part  of  the  research  effort  was  expended  in  documenting  an  earlier 
version  of  the  threat  allocation  model  for  presentation  at  the  national 
ORSA/TIMS  meetings;  the  resulting  paper  is  discussed  in  Section  IV. 


SECTION  II 


THREAT  ALLOCATION  MODEL 
2.1  Threat  Allocation  Decision 

One  of  the  major  tasks  faced  by  the  military  planner  in  specifying 
defense  mission  requirements  is  assessing  the  nature  of  the  threat 
which  must  be  countered.  With  respect  to  BMD  mission  analysis,  the 
analyst  must  determine  how  an  assumed  threat  would  likely  be  targeted 
against  assets  of  importance  and  what  the  resulting  damage  would  be. 

This  problem  has  been  treated  with  threat  allocation  models  which 
"allocate"  the  threat  over  the  assets  in  such  a  way  as  to  achieve  some 
explicitly  stated  objective,  e.g.,  maximization  of  value  of  assets 
destroyed.  An  example  of  this  type  of  threat  allocation  model  is 
shown  in  Appendix  X. 

This  research  had  as  one  of  its  objectives  the  development  of  a 

* 

threat  allocation  model  which  would  differ  from  existing  models  in  two 
major  respects.  First,  the  allocation  logic  would  be  based  on  simple 
decision  heuristics  rather  than  optimization  or  enumeration  algorithms. 
Second,  the  procedure  would  be  developed  for  running  on  a  microprocessor 
rather  than  a  large  mainframe  computer.  The  resulting  model  incorpor¬ 
ates  rather  straightforward  logic  which  closely  replicates  military 
strategy  and  it  has  been  run  on  an  Apple  II  using  Apple  BASIC. 

The  research  is  presented  in  three  parts.  The  first  part  describes 
the  heuristics  upon  which  the  program  is  based.  Some  examples  of  the 
application  of  the  model  are  described  in  the  second  part  of  the 
discussion.  The  final  part  of  the  discussion  is  a  critique  of  the  model. 
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2.2  Allocation  Heuristics 

In  attempting  to  more  realistically  model  the  threat  allocation 
decision,  consideration  was  given  to  incorporating  a  "threat  strategy" 


into  the  decision  logic.  Once  the  threat  strategy  has  been  defined, 
allocations  are  made  on  the  basis  of  a  simple  allocation  rule. 

2.2.1  Threat  Strategy 

The  threat  strategy  defines  military  objectives  of  the  threatening 
force  which  are  to  be  achieved  in  actual  operations.  Included  are  kill 
priorities,  kill  criteria,  and  kill  objectives. 

2. 2. 1.1  Kill  Priorities.  Each  asset  is  assigned  a  priority 
corresponding  to  the  importance  attached  to  it  by  military  planners  of 
the  threatening  force.  For  example,  if  a  major  objective  of  the  strike 
is  to  achieve  air  superiority,  air  bases  would  be  assigned  a  kill 
priority  of  1. 

2. 2. 1.2  Kill  Criteria.  Each  asset  is  assigned  a  kill  criterion 
corresponding  to  the  degree  of  certainty  the  threatening  force  wishes 
to  achieve  in  destroying  the  asset.  For  example,  the  threatening  force 
might  wish  to  be  99  percent  certain  that  air  bases  are  destroyed. 


whereas  a  90  percent  assurance  may  be  acceptable  for  other  assets. 

Then,  in  making  allocations,  sufficient  r.v.'s  must  be  targeted  to 
airbases  to  assure  that  the  combined  kill  probability  equals  or  exceeds 


0 


2. 2. 1.3  Kill  Objectives.  Each  class  of  assets  is  assigned  a  kill 
objective  corresponding  to  the  percentage  of  assets  in  the  class  which 


the  threat  should  successfully  destroy.  For  example,  it  may  be 
necessary  to  destroy  95  percent  of  the  airbases  to  achieve  air 
superiority. 


2.2.2  Allocation  Rule 

Once  the  threat  strategy  is  defined,  it  is  a  relatively  simple 
matter  to  search  the  asset  list  in  kill  priority  sequence  assigning 
r.v.'s  to  each  asset  in  a  particular  asset  category  until  the  required 
percent  of  assets  in  that  category  is  destroyed  with  probability  equal 
to  or  greater  than  the  required  kill  criterion  for  the  asset.  All  that 
remains  to  completely  define  the  allocation  procedure  is  to  specify  the 
rule  for  assigning  r.v.'s  to  assets.  The  rule  followed  in  the  procedure 
described  here  is  to  assign  from  available  r.v.'s  the  one  having  the 
minimum  P<-SK  for  the  asset  being  considered. 


2.2.3  Allocation  Procedure 

A  complete  description  of  terminology  and  notation  used  in  the 
allocation  model  is  contained  in  Appendix  I.  A  detailed  narrative  of 
the  allocation  logic  is  presented  in  Appendix  II  with  a  flowchart  of  the 
logic  in  Appendix  III.  A  listing  of  the  BASIC  computer  program 
developed  appears  in  Appendix  IV. 

2.3  Model  Applications 

To  demonstrate  the  use  of  the  model  in  threat  allocation  decisions, 
a  hypothetical  problem  described  in  a  paper  presented  at  the  national 
ORSA/TIMS  meeting  is  used.  The  paper  which  is  included  as  Appendix  X 
describes  a  tactical  situation  involving  four  asset  types  and  four  r.v. 
systems.  The  threat  definition  for  this  problem  is  shown  in  Table  1  of 
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the  Appendix,  the  asset  structure  is  given  in  Table  2,  and  single  shot 
kill  probabilities  are  from  Table  3. 

2.3.1  No  Defense  Scenario 

The  first  scenario  assessed  with  the  heuristic  model  was  a  no 
defense  case  in  which  all  assets  in  each  of  the  four  categories  were 
unprotected.  Sample  output  for  the  no  defense  case  is  given  in  Ar  ?ndix 
V.  From  the  echo  report  of  input  data,  it  may  be  seen  that  the  e  ^ts 
are  ranked  in  descending  order  by  kill  priority  with  type  1  asset 
ranked  first  and  type  4  assets  ranked  last.  Notice  also  that  the  . 
criterion  for  type  1  assets  is  .99  while  .90  is  specified  for  other 
assets.  Furthermore,  the  kill  objective  for  each  asset  category  is  .95. 
Each  of  the  r.v.  systems  in  the  illustration  has  a  reliability/ 
availability  factor  of  .90. 

The  allocation  model  commits  a  total  of  75  type  1  r.v.'s  to  type  1 
assets  destroying  all  15  assets.  The  remaining  type  1  r.v.'s  are  tar¬ 
geted  to  type  2  assets  as  are  all  of  the  type  3  and  4  r.v.'s,  thus 
destroying  15  of  the  45  type  2  assets.  Note  from  the  output  that  no 
assets  of  type  3  or  4  are  killed  and  that  none  of  the  type  2  r.v.'s  are 
allocated.  This  is  obviously  a  shortcoming  of  the  allocation  heuristic 
and  will  be  mentioned  subsequently. 

2.3.2  Defense  Scenarios 

Several  scenarios  were  assessed  varying  the  defense  assigned  to 
each  of  the  assets.  In  all  cases,  interceptors  were  assigned  uniformly 
to  the  assets  and  the  probability  of  successful  intercept  was  assumed 
to  be  .90.  From  Appendix  V  it  may  be  seen  that  when  one  interceptor  is 
assigned  to  each  asset,  all  available  type  1  r.v.'s  must  be  committed  to 
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type  1  assets  in  order  to  destroy  all  15  of  the  assets.  All  available 
type  3  and  4  r.v.'s  are  allocated  to  type  2  assets  destroying  13  of  the 
45  assets.  Table  2.1  shows  the  effect  of  the  number  of  interceptors 
committed  to  each  asset  on  the  number  of  assets  destroyed.  Assigning 
one  interceptor  to  each  asset  essentially  buys  two  type  2  assets. 
Assigning  two  interceptors  to  each  asset  buys  one  type  1  asset  (rather 
than  allocating  r.v.'s  to  all  15  type  1  assets,  the  model  targets  only 
14  which  satisfies  the  kill  objective  for  that  category).  When  four 
interceptors  are  assigned  to  each  asset,  the  model  begins  to  target 
type  2  r.v.'s  to  type  2  assets.  The  last  defense  scenario  considered 
was  to  assign  eight  interceptors  to  each  asset;  from  Table  2.1  it  may 
be  seen  that  the  results  are  the  same  as  when  four  interceptors  are 
assigned  --  the  only  difference  is  that  a  greater  numKer  of  type  2  r.v.'s 
is  required. 

2.4  Model  Critique 

Limited  experience  with  the  heuristic  model  to  date  suggests  that 
results  compare  favorably  with  results  obtained  using  more  sophisticated 
algorithms.  For  example,  if  the  no  defense  allocation  results  in  terms 
of  assets  destroyed  are  valued  using  the  asset  values  reflected  in 
Table  2  of  Appendix  X,  approximately  49  percent  of  the  total  value  of 
the  assets  would  be  destroyed.  Referring  to  Figure  4  of  Appendix  X,  it 
may  be  seen  that  roughly  the  same  percentage  value  of  assets  would  be 
destroyed  by  the  allocation  model  used  in  that  study  (at  the  1.0  Threat 
Level ) . 
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Table  2.1.  Effect  of  Defense  Options  on  Number  of  Assets  Destroyed 


Number  of 
Interceptors 
Per  Asset 

Number  of  Assets  Destroyed 

Type  1 

Type  2 

Type  3 

Type  4 

0 

15 

15 

0 

0 

1 

15 

13 

0 

0 

2 

14 

13 

0 

0 

4 

14 

13 

0 

0 

8 

14 

13 

0 

0 

The  model  appears  to  have  enough  potential  to  warrant  further 
examination  with  a  view  toward  enhancement.  For  instance,  integrating 
second  order  heuristics  may  overcome  the  shortcoming  mentioned  earlier. 
If  r.v.'s  remained  unused  after  the  first  allocation  pass,  perhaps  a 
second  pass  with  adjusted  P<-SK  values  could  yield  an  improved  alloca¬ 
tion.  Or  perhaps  a  procedure  similar  to  Vogel's  Approximation  Method 
used  in  transportation  problems  could  be  used  to  locate  efficient 
allocations.  A  number  of  simple  heuristics  appear  to  have  application 
in  this  regard. 


■  II  !■  I  I  III  I—  1 1 1  I  I  l  I  — H  I  I  I  I  I  II  HI . I— II  i  Mill  Mil  I  I  I 
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SECTION  III 

R&D  PROJECT  PLANNING  f "TWORK  SIMULATION 
3.1  R&D  Project  Planning 

One  of  the  most  difficult  tasks  in  project  management  in  an  R&D 
environment  is  activity  scheduling  including  the  related  task  of  esti¬ 
mating  duration,  start,  and  completion  times  for  individual  activities 
and  entire  projects.  The  task  is  complicated  by  the  inherent 
uncertainty  associated  with  R&D  activity  and  by  the  interdependencies 
which  exist  between  activities  and  projects.  Project  scheduling 
problems  have  traditionally  been  treated  with  PERT/CPM  techniques; 
however  because  of  the  high  levels  of  inherent  uncertainty,  attention 
has  been  focussed  on  simulation  models  as  a  way  of  providing  the  time 
estimates  needed  to  effectively  manage  R&D  efforts. 

Unfortunately,  one  of  the  frequently  cited  limitations  of 
simulation  is  that  it  is  not  sufficiently  flexible  (or  general)  to  be 
of  much  use  in  a  dynamic  environment.  There  does  appear  to  be  a  legi¬ 
timate  need  for  a  project  network  simulator  that  is  sufficiently  general 
to  be  applicable  to  the  majority  of  R&D  cases.  Thus,  one  of  the 
emphases  of  this  research  was  to  develop  a  generalized  project  network 
simulator  which  could  be  easily  adapted  to  model  a  variety  of  R&D 
network  situations. 

The  research  is  discussed  in  three  parts.  The  first  part  presents 
a  general  R&D  network  representation.  The  network  simulation  model  is 
described  in  the  second  part  of  the  discussion  along  with  data  inputs 
required  and  outputs  generated  by  the  model.  The  final  part  of  the 
discussion  is  a  critique  of  the  network  simulator. 
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In  order  to  develop  a  generalized  R&D  network  simulator,  it  is 
first  necessary  to  specify  a  framework  which  can  be  used  to  represent  a 
variety  of  R&D  projects.  The  framework  devised  in  this  research  is  a 
generalized  project  activity  representation  which  can  itself  be 
networked  to  represent  complex  R&D  projects. 

3.2.1  Individual  Project  Representation 

Figure  3.1  shows  the  individual  project  network  representation.  In 
developing  this  framework,  an  attempt  was  made  to  include  every  activity 
which  could  occur  in  an  R&D  project.  The  main  activity  sequence  is  from 
left  to  right  and  includes  the  following  distinct  activities: 

•  System  Study.  Activities  related  to  definition  of  project 
objectives/requirements. 

•  RFP.  Preparation  and  distribution  of  requests  for 
proposal . 

•  Contractor  Proposal.  Activities  undertaken  by  contractors 
in  response  to  the  RFP. 

•  Award.  Assessment  and  evaluation  of  various  contractor 
proposals  and  award  of  contract. 

•  Contractor  Activity.  Actual  research  and  development 
effort  by  contractor  as  required  by  contract. 

•  Evaluation.  Evaluation  of  contractor  effort  with  respect 
to  project  objectives/requirements. 

In  addition  to  these  major  activities,  the  network  contains  four  restart 
loops  which  correspond  to  unsuccessful  activity  of  one  form  or  another. 
The  four  loops  are: 

•  Redefine  Project.  A  redefinition  of  the  project  might 
be  required  for  a  variety  of  reasons  including:  budget 
considerations,  technology  limitations,  etc. 


Generalized  Network  for  R&D  Project  Activity. 


•  Proposals  Unacceptable.  The  RFP  phase  may  have  to  be 
repeated  due  to  inadequate  project  specification, 
budget  considerations,  contractor  problems,  etc. 

•  Additional  Activity.  After  the  contract  evaluation, 
the  contractor  may  be  required  to  undertake  additional 
activity  to  complete  the  contract. 

•  Solution  Unacceptable.  Alternatively,  the  evaluation 
may  show  that  the  effort  failed  with  respect  to 
objectives  and  that  a  new  effort  is  required. 

3.2.2  A  Generalized  Network 

Figure  3.2  shows  a  complex  network  composed  of  six  individual 
project  networks  of  the  form  described  in  the  previous  paragraph. 

The  particular  network  shown  includes  individual  interceptor,  data  pro¬ 
cessing,  and  sensor  projects  which  must  be  integrated  in  follow-on 
projects  in  order  to  complete  the  complex  development  represented  by 
the  composite  network. 

It  should  be  noted  that  individual  project  networks  can  be 
combined  in  whatever  way  is  necessary  in  order  to  represent  the  inter¬ 
dependencies  inherent  in  a  complex  R&D  effort.  Such  complex  efforts 
routinely  involve  literally  scores  of  individual  projects. 

3.3  Network  Simulator 

A  UNIVAC  1100  GPSS  simulation  model  of  the  network  shown  in  Figure 

3.2  was  written  and  run  to  produce  1,000  replications  of  the  complex 
project.  Terminology  and  notation  incorporated  in  the  model  are  shown 
in  Appendix  VI,  program  logic  is  detailed  in  Appendix  VII,  and  a 
flowchart  of  model  logic  appears  in  Appendix  VIII. 


zed  Complex  Network  of  R&D  Projects. 


3.3.1  6PSS  Program 

The  GPSS  program  includes  three  major  sections.  The  first  section 
is  primarily  definitional  and  includes  a  matrix  named  VAL( I , J )  which  is 
used  to  input  mean  activity  times  and  modifiers,  probability  values  for 
unsuccessful  activities,  and  precedence  relationships.  Each  row  in  the 
matrix  represents  an  individual  project;  columns  are  as  defined  in 
statement  numbers  41-63  of  the  program  listing.  The  second  section  of 
the  program  models  the  actual  sequence  of  activities  from  system  study 
through  contract  evaluation — statement  numbers  83-152.  The  last  seg¬ 
ment  of  the  program  is  used  for  collecting  statistics  of  interest  to 
project  management. 

Use  of  a  matrix  for  inputting  project  descriptive  data  makes  it 
extremely  easy  to  change  these  values  for  "what  if"  analysis.  It  is 
not  necessary  to  make  changes  to  statements  within  the  program.  All 
that  is  required  is  to  make  appropriate  changes  to  the  matrix  INITIAL 
statements,  statement  numbers  65-77. 

3.3.2  Simulator  Output 

Standard  GPSS  output  for  this  model  is  fairly  extensive  amounting 
to  about  eight  pages;  furthermore  the  output  is  difficult  to  understand 
without  a  thorough  knowledge  of  GPSS.  For  this  reason  a  FORTRAN  report 
generator  was  linked  to  the  simulator  via  the  GPSS  HELP  statement. 
Important  GPSS  output  is  summarized  in  a  report  which  should  communicate 
to  project  managers  having  little  familiarity  with  simulation;  an 
example  is  shown  on  page  57.  The  report  gives  project  start  and  com¬ 
pletion  times,  project  durations,  and  statistics  on  failures.  For 
example,  for  the  six  project  network  depicted  in  Figure  3.2,  the  final 
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project  (project  six)  would  commence  1,493  time  units  from  the  start 
.  date  and  would  be  completed  2,167  time  units  from  the  start  date.  Out 

of  1,000  replications  of  project  6,  the  system  study  phase  had  to  be 
redone  4  times,  the  contractor  had  to  perform  additional  work  9  times, 
and  the  entire  project  failed  once. 

i 

3.4  Model  Critique 

The  value  to  project  managers  of  the  kind  of  information  available 

I  from  the  simulator  should  be  obvious.  Project  scheduling  could  be  done 

with  greater  accuracy  because  of  the  availability  of  reliable  time 
estimates.  Various  scenarios  could  easily  be  assessed  by  changing  input 
data  and  rerunning  the  simulation.  The  simulator  is  limited  in  at  least 

! 

two  respects.  First,  the  output  will  only  be  as  good  as  the  input  data; 
some  of  the  probability  estimates  and  activity  duration  times  may  be 
difficult  to  obtain  especially  when  no  prior  R&D  experience  exists. 
Second,  to  change  the  network  formats  presented  in  Figure  3.1  and  3.2 
would  require  changing  the  GPSS  program,  a  task  which  would  require 
expert  programming  capability. 


SECTION  IV 


A  THREAT  ALLOCATION  MODEL  FOR  TACTICAL  WARFARE 

A  final  task  of  the  research  was  to  document  an  earlier  version 
of  the  threat  allocation  model  for  presentation  at  the  ORSA/TIMS  Joint 
National  Meeting  in  San  Diego,  California,  October  25-27,  1982.  The 
paper  presented  at  the  conference  is  included  in  its  entirety  in 
Appendix  X. 
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TERMINOLOGY  AND  NOTATION  USED  IN  THREAT  ALLOCATION  PROGRAM 


Program 

Notation 

Standard 

BMD 

Notation 

Definition 

T 

I 

The  number  of  asset  types,  i=l,  2,  m 

H 

J 

The  number  of  reentry  vehicle  types, 
j“l,  2,  •  > • ,  n 

P(T,H) 

pij 

The  probability  of  killing  a  type  i  asset 
with  a  single  reentry  vehicle  of  type  j 

A(T) 

The  number  of  type  i  assets  available 

Y(T) 

Yt 

The  kill  criteria  for  asset  type  i 

R(T) 

Rf 

The  kill  priority  for  asset  type  i 

O(T) 

°i 

The  kill  objective  for  asset  type  i 

B(H) 

Bi 

The  number  of  type  j  reentry  vehicles  available 

Q(H) 

The  name  of  asset  type  i 

U$(T) 

The  name  of  asset  type  i 

NN(T) 

Ni 

The  number  of  interceptors  available  to 
defend  asset  type  i 

1 1  (T) 

pki 

The  probability  that  a  terminal  interceptor 
kills  a  reentry  vehicle  attacking  asset  i 

V 

xu 

The  number  of  type  j  reentry  vehicles  that 
must  be  allocated  to  each  asset  of  type  i 

E 

For  a  selected  asset,  E  is  the  highest  single 
shot  kill  probability  given  the  j  type  reentry 
vehicle  available 

W 

A  counter  which  indicates  the  number  of 
complete  allocations  made 

R 

Index  number  used  as  a  starting  point  in  the 
search  for  the  asset  type  with  the  highest 
kill  priority 

APPENDIX  I 


(CONTINUED) 


Standard 

Program  BMD 

Notation  Notation  Definition 


C 

U 

X 


S 


An  intermediate  index  used  to  arrive  at  the 
final  reentry  vehicle  allocation 

The  intermediate  probability  of  survival  for 
the  selected  asset  type 

The  aggregate  kill  probability  for  asset 
type  i  given  the  allocation  of  C  number  of 
3  type  reentry  vehicles 

The  number  of  random  variables  to  be  allocated 
to  each  asset  of  type  i  if  the  number  of  reentry 
vehicles  is  not  sufficient  to  lead  to  a 
complete  destruction  of  that  asset 


20 


APPENDIX  II 

THREAT  ALLOCATION  LOGIC 

1.  Block  1.  Read  input  data: 

NN(T),  II (T) ,  U$(T),  P(T,H),  A(T),  Y(T) ,  R(T),  0(T), 

B(H)  and  Q(H)  for  T=1 ,  2,  ...»  I  and  H=l,  2,  J 

2.  Blocks  2-4.  Compute  desired  kill  objective  for  each  asset 
type  and  integerize  the  result 

A(T)  =  Int[A(T)  *  0(T)  +  .99]  for  T=1 ,  2,  . ..,  I 

3.  Blocks  5-9.  Adjust  the  single  shot  kill  probabilities  for  each 
reentry  vehicle  type  to  reflect  the  reliability/availability 
factor  of  that  random  variable 

P(T,H)  =  P(T,H)  *  Q(J)  for  T=1 ,  2 . I  and  H=1 ,  2 . J 

4.  Block  10.  Set  W=1  marking  the  start  of  the  allocation  algorithm. 

W  will  be  incremented  by  one  whenever  an  asset  is  chosen  for  an 
allocation.  Set  R=  999  which  will  serve  as  a  starting  search  point 
for  the  next  step. 

5.  Blocks  11-14.  Select  the  asset  with  the  highest  kill  priority 
(where  1  indicates  the  highest  kill  priority). 

6.  Block  15.  Set  E=-999  which  will  serve  as  a  starting  search  point 
for  the  next  step. 

7.  Blocks  16-19.  For  the  asset  selected  in  step  5,  select  the  reentry 
vehicle  that  has  the  highest  single  shot  kill  probability. 
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(CONTINUED) 

8.  Block  20.  For  defended  assets,  the  single  shot  kill  probability 
is  adjusted  to  account  for  the  interceptor's  defense. 

TR  =  E  *  (1  -  11(A)) 

9.  Blocks  21-29.  Determine  min  C  for  which 

i  -  [(i  -  tr)nn(a)  *  (i  -  e)c-nn(a>]  >  Y(A) 

10.  Block  30.  Set  V  =  C  where  V  is  the  minimum  number  of  reentry 
vehicles  to  be  allocated  to  the  selected  asset. 

11.  Block  31.  Determine  if  there  is  a  sufficient  number  of  the 
selected  reentry  vehicle  to  destroy  the  selected  asset. 

12.  Blocks  32,  44-54.  If  there  is  a  sufficient  number  of  the 
selected  reentry  vehicles  then  that  number  should  be  reduced 
by  the  number  needed  to  destroy  the  selected  asset  (Block  32). 
Then  the  allocations  determined  in  steps  9  and  10  are  printed 
(Blocks  44-47)  and  the  asset  single  shot  kill  probabilities  are 
deleted  (Blocks  48-50)  since  no  more  allocations  will  be  made 
to  that  asset.  The  asset  is  then  given  an  extremely  low  kill 
priority  ( R( A)  =  999)  so  that  it  will  not  be  considered  for  any 
further  allocations  (Block  51).  If  the  number  of  complete  allo¬ 
cations  (those  allocations  that  lead  to  the  total  destruction  of 
a  selected  asset)  is  equal  to  the  number  of  asset  types  avail¬ 
able  the  program  stops,  otherwise  the  program  goes  back  to 

step  5  (Blocks  52-54). 
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(CONTINUED) 

Blocks  33-35,  40-43.  If  the  number  of  reentry  vehicles  is  not 
sufficient  to  destroy  the  selected  asset  then  the  available 
number  of  reentry  vehicles  is  exhausted  to  destroy  as  many  as 
possible  of  the  selected  asset  type  (Blocks  33,  34).  The  number 
of  assets  available  is  then  reduced  by  the  number  that  has  been 
destroyed,  the  number  of  reentry  vehicles  is  set  equal  to  zero, 
and  the  allocations  are  then  printed  (Blocks  35,  40).  The 
reentry  vehicle  single  shot  kill  probabilities  are  then  set  to 
zero.  Since  this  reentry  vehicle  can  not  be  used  for  any  further 
allocations  (Blocks  41,  42,  43),  the  program  then  returns  to 
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THREAT  ALLOCATION  PROGRAM  FLOWCHART 


E  =  P(A,H) 
B  =  H 


19 


27 


P(T,B)  =  0 


41 


31 


1  LIST 

2  HOME  i  PRINT  "  ":  PRINT  "  **  THREAT  ALLOCATION 

DEL  **"i  PRINT  "  "J  PRINT  ”  M 

^  X  —  lot J  =  ^ 

5  PRINT*:  PRINT  X  PRINT  "  RUN  DESCRIPTION:":  PRINT  "  " 

6  PRINT  "  ORSA/TIMS:  NO  DEFENSE  "X.  PRINT  "  " :  PRINT  "  " 

25  PRINT  :  PRINT  :  PRINT  "  INPUTS:  " PRINT  "  " 

26  PRINT  :  PRINT  :  PRINT  "  1.  KILL  PROBABILITIES" 

27  PRINT  :  PRINT  "  REENTRY  VEHICLE" :  PRINT  " 

28  PRINT  "  ASSET/ZONE  123 

4" 

30  dim  p(i,j>:  dim  a<d:  dim  y(I>:  dim  r<i>:  dim  o<i>:  dim  b(j>:  dim  q 
:  dim  u*<i>:  dim  nn(I):  dim  ikd 


32 

FOR  T  =  1  TO 

i: 

READ 

NN ( T  > : 

NEXT 

33 

FOR  T  =  1  TO 

i: 

READ 

ii(T) : 

NEXT 

35 

FOR  T  =  1  TO 

it 

READ 

u$  <  t  > : 

NEXT 

"10 

FOR  T  =  1  TO 

i 

42 

FOR  H  =  1  TO 

j 

44 

READ  P(T,H) 

46 

NEXT 

48 

NEXT 

5C 

FOR  T  =  1  TO 

i 

51 

PRINT  " 

"JU*<T> J 

ii  it 

t 

52 

FOR  H  =  1  TO 

J 

53 

PRINT  P ( T » H ) 

* 

54 

NEXT 

55 

PRINT 

56 

NEXT 

58 

PRINT  "  " 

90 

FOR  T  ■  1  TO 

I 

100 

READ  A(T) 

110 

NEXT 

120 

FOR  T  =  1 

TO  I 

130 

READ  Y(T) 

140 

NEXT 

150 

FOR  T  =  1 

TO  I 

153 

READ  R<T) 

157 

NEXT 

160 

FOR  T  =  1 

TO  I 

170 

READ  0(T> 

180 

NEXT 

190 

FOR  H  =•  1 

TO  J 

200 

READ  B(H) 

210 

NEXT 

220 

FOR  H  =  1 

TO  J 

230 

READ  Q(H) 

240 

NEXT 

250 

PRINT  "  2 

♦  ASSET  CHARACTERISTICS":  PRINT  "  " 

251 

PRINT  " 
LL" 

ASSET/  KILL 

KILL 

253 

PRINT  " 
JECTIVES" 

ZONE  NUMBER  PRIORITY 

CRITERIA 

257 

FOR  T  =  1 

TO  I 

258 

PRINT  " 

"iU*<T> ,"  "JA<T)»R(T),Y<T)»0<T> 
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260 

NEXT 

262 

PRINT 

II 

(i 

264 

PRINT 

II 

3.  THREAT  CHARACTERISTICS":  PRINT  "  " 

267 

PRINT 

tt 

REENTRY  RELIABILITY/  " 

269 

PRINT 

•  1 

VEHICLE  NUMBER  AVAILABILITY" 

275 

FOR  H 

= 

1  TO*  J 

277 

PRINT 

II 

"JH,"  "}B<H),Q(H) 

279 

NEXT 

282 

PRINT 

II 

II 

285 

PRINT 

II 

4.  INTERCEPTOR  CHARACTERISTICS":  PRINT  "  " 

287 

PRINT 

II 

NUMBER  OF" 

290 

PRINT 

tl 

ASSET/  INTERCEPTORS  PROBABILITY  OF" 

291 

PRINT 

II 

ZONE  PER  ASSET  INTERCEPT" 

292 

FOR  T 

= 

1  TO  I 

.294 

PRINT 

II 

";u*<T),n  ":nn<t>,"  "iikt) 

298 

NEXT 

• 

299 

PRINT 

II 

II 

300 

REM  STEP  TWO 

310 

FOR  T 

35 

1  TO  I 

320 

A  (  T )  = 

INT  <  <A(T)  *  Q ( T ) )  +  *9999) 

330 

NEXT 

340 

FOR  H 

35 

1  TO  J 

345 

FOR  T 

= 

1  TO  I 

350 

P(T,H) 

S3 

P(T,H>  *  Q(H> 

355 

NEXT 

360 

NEXT 

361 

PRINT 

II 

output:-:  print  ••  " 

365 

PRINT 

II 

ASSET/  •  ASSETS  REENTRY  R.V.'S  PER 

TOTAL 

R.V.'S  " 

.  366 

PRINT 

•  1 

ZONE  KILLED  VEHICLE  ASSET 

ALLOCATED" 

500  REM  STEP  3-FIND  THE  HIGHEST  PRIORITY 

505  W  =  1 

510  R  =  99999 

520  FOR  T  =  1  TO  I 

530  IF  R(T )  <  R  GOTO  550 

540  GOTO  560 

550  R  =  R(T) ♦ A  =  T 

560  NEXT 

580  REM  '  STEP  4-FIND  THE  HIGHEST  PROBABILITY  WITHIN  ONE  ROW 
590  E  -  -  99999 

600  FOR  H  -  1  TO  J 
'610  IF  P< A»H)  >  E  GOTO  630 
620  GOTO  640 
630  E  =  P<A,H):e  =  H 
640  NEXT 

650  IF  E  =  0  GOTO  955 

690  REM  STEP  5-START  THE  ALGORITHM 

700  TR  =  E  *  <1  -  11(A)) 

710  FOR  C  =  1  TO  100 

715  IF  C  >  NN( A)  GOTO  721 

716  U  =  <1  -  TR)  A  C 

717  X  =  1  -  U 
7.19  LL  *  U 
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I 


.v 


720  GOTO  730 

721  IF  C  =  1 . GOTO  723 

722  GOTO  724 

723  LL  =  1 

724  U  =  LL  *  <  < 1  -  E>  A  (C  -  NN ( A >  > ) 

725  X  a  (1  -  U) 


730 

IF  X  >  =  Y< A)  GOTO  760 

*  “ 

750 

NEXT 

760 

V  a  C 

1 

770 

IF  A‘(A)  *  V  <  =  B < B )  GOTO 

J 

780 

S  =  B(B)  /  V 

782 

S  =  INT  (S  +  ,99999999) 

783 

A< A)  a  a<A)  -  S 

785 

B < B )  =  B<B>  -  S  *  V 

787 

IF  B(B)  <  0  THEN  GOTO  790 

m 

788 

IF  S  =  0  GOTO  800 

f  ■; 

L*«' 

789 

GOTO  795 

Cv 

790 

S  =  S  -  1 

f- 

791 

IF  S  =  o  GOTO  800 

795 

PRINT  "  “  Jl)$C  A)  ,  " 

800 

FOR  T  =  1  TO  I 

B 

810 

P<T,B)  a  0 

JB, 


820  NEXT 
825  B<B)  -  B<B) 
830  GOTO  590 
880  B(B)  =  BCB) 

885  IF  B(B)  < 

886  IF  AC  A)  = 

887  GOTO  895 


-  S  *  V 

-  < A< A)  * 
0  GOTO  890 
0  GOTO  900 


V) 


890 

AC  A)  a 

ACA)  -  1 

L  **< 

891 

IF  AC  A)  a  0  GOTO  900 

-V 

895 

PRINT 

"  '*  J  U$  <  A )  ,  "  "  $  A  C  A )  ,  "  "  }  B ,  "  "JV," 

m 

900 

FOR  H 

o 

H 

H 

ii 

m 

910 

P(A,H) 

a  0 

»v 

920 

NEXT 

y: 

930 

RCA)  = 

9999 

t  • 

s*  • 

955 

W  =  W 

HlJ  IF  W  >  I  GOTO  998 

o 

960 

GOTO  510 

■A 

998 

END 

0 

1970 

DATA 

0, 0,0, Q,0,0,D, 0,0,0 

£ 

1980 

DATA 

0  •  0  ,  C  ,  Q  ,  Q  ,  0  ,  C  ,  0  ,  t:  ,  0 

.'C- 

1990 

DATA 

1/1, 1/2 ,2/1, 2/2, 2/3, 3/1 ,3/2* 3/3 #4/1 #4/2 

>y* 

2000 

DATA 

*7 , ♦ 30 , ♦ 5 , ♦ A 5 

y: 

2010 

DATA 

•7,,3,,0,,65 

*  •- 

2020 

DATA 

,11  ,  ,05, ,08, ,1 

H 

2030 

DATA 

,11, ,00, ,08, ,1 

k. 

2040 

DATA 

,11,  ,00, ,00, ,1 

2050 

DATA 

♦06, ,06, ,04, ♦ 0^ 

2060  DATA  . 06 , . 0 0 , ♦ 04 , . 04 
2070  DATA  . 06 , . 00 , . 00 , ♦ 04 
2080  DATA  ♦  07, ♦ 15, . 15, . 06 
2090  DATA  . 07, . 00 , ♦ 15, . 06 
3100  DATA  5,10,15,15,15,20,10,5,10,15 


^  \  ; 


♦,S  *  V 


" JAC A)  *  V 
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3110  DATA 
3120  DATA 
3130  DATA 
3140  DATA 
3150  DATA 
1 


99 . .  99 ,  ♦ 9 , ♦ 9 ,  *  9 ,  . 9 , « 9 , , 9  ,9  ,9 
,2,3,4,5,6,7,8,9,10 

95. . 95. .95. .95. .95, « 95, ,95, ,95, ,95, ,95 

.00,500,200,200  ' 

9. . 9. .9. .9 
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rrr  «r:  >v  » " 1  r*  f 


1 


3RUN 


**  THREAT  ALLOCATION  MODEL  ** 


RUN  description: 

ORSA/TIMSJ'  NO  DEFENSE 

inputs: 

1.  KILL  PROBABILITIES 


REENTRY  VEHICLE 
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ASSET/ZONE 

1 

2 

3 

4 

1/1 

.7 

.3 

.  5 

.65 

1/2 

.7 

.3 

0 

.65 

2/1 

.11 

.05 

.08 

.1 

2/2 

.11 

0 

.08 

*1 

2/3 

.11 

0 

0 

.1 

3/1 

.06 

.06 

.04 

.04 

3/2 

.06 

0 

♦  04 

.04 

3/3 

.06 

0 

0 

.04 

4/1 

.07 

.15 

.15 

.06 

4/2 

.07 

0 

.15 

.06 

2.  ASSET  CHARACTERISTICS 

ASSET/ 

KILL 

KILL 

KILL 

ZONE 

NUMBER 

PRIORITY 

CRITERIA 

OBJECTIVES 

1/1 

5 

1 

.99 

.95 

1/2 

10 

2 

.99 

.95 

2/1 

15 

3 

.9 

.95 

2/2 

15 

4 

♦  9 

.95 

2/3 

15  ■ 

5 

♦  9 

.95 

3/1 

20 

6 

.9 

.95 

3/2 

10 

7 

.9 

.95 

3/3 

5 

S 

.9 

.95 

4/1 

10 

9 

♦  9 

.95 

4/2 

15 

1° 

.9 

.95 

3*  THREAT 

CHARACTERISTICS 

• 

REENTRY 

RELIABILITY/ 

VEHICLE 

NUMBER 

AVAILABILITY 

1 

100  . 

♦  9 

2 

500 

,9 

3 

200 

,9 

4 

200 

.9 
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4.  INTERCEPTOR  CHARACTERISTICS 


ASSET/ 

ZONE 

1/1 

1/2 

2/1 

2/2 

2/3 

3/1 

3/2 

3/3 

4/1 

4/2 

NUMBER  OF 
INTERCEPTORS 
PER  ASSET 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

PROBABILITY  OF 
INTERCEPT 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

output: 

ASSET/ 

ASSETS 

REENTRY 

R.V.'S  PER 

TOTAL  R» V. 

ZONE 

KILLED 

VEHICLE 

ASSET 

ALLOCATED 

1/1 

5 

1 

5 

25 

1/2 

10 

1 

5 

50 

2/1 

1 

1 

23 

23 

2/1 

8 

4 

25 

200 

2/1 

5 

3 

31 

155 

2/2 

1 

3 

31 

31 

3 


T 


r 


T 


1 


IRUN 


X*  THREAT  ALLOCATION  MODEL  *x 

RUN  description: 

ORSA/TIMS:  DEFENDED 


inputs: 

1*  KILL  PROBABILITIES 

REENTRY  VEHICLE 


ASSET/ZONE 

1 

2 

3 

4 

1/1 

♦  7 

.3 

,  5 

♦  65 

1/2 

.7 

.3 

0 

.65 

2/1 

♦  11 

♦  05 

♦  08 

.1 

2/2 

,11 

0 

♦  08 

.1 

2/3 

,11 

0 

0 

.1 

3/1 

,06 

.  06 

.04 

.04 

3/2 

,06 

0 

.04 

.04 

3/3 

,06 

0 

0 

.04 

4/1 

,07 

.15 

♦  15 

.06 

4/2 

,07 

0 

.15 

.06 

2.  ASSET  CHARACTERISTICS 

ASSET/ 

KILL 

KILL 

KILL 

ZONE 

NUMBER 

PRIORITY 

CRITERIA 

OBJECTIVES 

1/1 

5 

1 

.99 

.95 

1/2 

10 

2 

.99 

.95 

2/1 

15 

3 

.9 

♦  95 

2/2 

15 

4 

.9 

♦  95 

2/3 

15 

5 

.9 

.95 

3/1 

20 

6 

.9 

.95 

3/2 

10 

7 

♦  9 

♦  95 

3/3 

5 

8 

♦  9 

.95 

4/1 

10 

9 

♦  9 

.95 

4/2 

15 

10 

♦  9 

.95 

3 .  THREAT 

CHARACTERISTICS 

REENTRY 

RELIAE'-ILITY/ 

VEHICLE 

NUMBER 

AVAILABILITY 

1 

100 

.9 

2 

500 

,9 

3 

200 

,9 

2.0  0 

,9 
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4.  INTERCEPTOR  CHARACTERISTICS 


ASSET/ 

NUMBER  OF 
INTERCEPTORS 

PROBABILITY  OF 

ZONE 

PER  ASSET 

INTERCEPT 

1/1 

1 

*9 

1/2 

1 

.9 

2/1 

1 

♦  9 

2/2 

1 

♦  9 

2/3 

•  1 

.9 

3/1 

1 

.9 

3/2 

1 

♦  9 

3/3 

1 

,9 

4/1 

1 

.9 

4/2 

1 

.9 

output: 

REENTRY 

R ♦ V . '  S  PER 

TOTAL  R.V 

VEHICLE 

ASSET 

ALLOCATE 

1 

6 

30 

1 

6 

60 

4 

26 

182 

3 

32 

192 

APPENDIX  VI 


TERMINOLOGY  AND  NOTATION 
USED  IN  R&D  PROJECT  PLANNING  NETWORK  SIMULATION 


Notation 


P 


5 


Definition 


Probability  of  an  unacceptable  problem  definition 

Probability  of  a  successful  evaluation 

Probability  of  a  washout  given  that  the  project 
has  been  unsuccessfully  evaluated 

Probability  of  an  unacceptable  problem  definition 
given  that  the  project  has  been  unsuccessfully 
evaluated  and  that  it  did  not  washout 

Probability  of  an  unsuccessful  prototype  development 
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APPENDIX  VII 

R&D  PROJECT  PLANNING  NETWORK  SIMULATION  LOGIC 

1.  Generate  five  projects  (Block  1)  and  number  them  sequentially 
(Block  2). 

2.  Place  the  projects  in  a  queue  (Block  3)  and  set  X$FLAG=  1 
(Block  4)  which  acts  as  a  flag  that  allows  a  project  to  start 
if  its  value  is  not  equal  to  zero. 

3.  Test  whether  X$FLAG  =  0  (Block  5);  if  yes  then  place  the  next 
project  in  a  wait  file  (Block  6)  and  increment  time  (Block  7) 
until  X$FLAG ?  0. 

4.  Subtract  1  from  the  value  of  X$FLAG  (Block  8)  and  select  the 
next  project  in  the  queue  (Block  9). 

5.  Read  the  mean  processing  time  and  modifier  for  stage  1  (Block  10) 
which  is  the  problem  definition  stage. 

6.  Start  stage  1  activity  (Block  11)  and  increment  time  by  one 
day  (Block  12)  until  the  duration  of  stage  1  activity  equals 
V$ACT.TIME  which  is  the  random  number  that  was  selected  from  an 
exponential  distribution  with  the  mean  and  modifier  assigned  in 
step  5. 

7.  Select  a  random  number.  If  the  number  selected  is  less  than  P^ 
then  go  to  step  5,  otherwise  go  to  step  8. 

8.  Read  the  mean  processing  time  and  modifier  for  stage  2  (Block  15) 
which  is  the  Research  Activity  Stage. 
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9.  Start  stage  2  activity  (Block  16)  and  increment  time  by  one 
day  (Block  17)  until  the  duration  of  stage  2  activity  equals 
V$ACT.TIME  which  is  the  random  number  that  was  selected  from  an 
exponential  distribution  with  the  mean  and  modifier  assigned  in 
step  8. 

10.  Read  the  mean  processing  time  and  modifier  for  stage  3  (Block  19) 
which  is  the  solution  proposal  stage. 

11.  Start  stage  3  activity  (Block  20)  and  increment  time  by  one  day 
(Block  21)  until  the  duration  of  stage  3  activity  equals 
V$ACT.TIME  which  is  the  random  number  that  was  selected  from  an 
exponential  distribution  with  the  mean  and  modifier  assigned  in 
step  10. 

12.  Select  a  random  number.  If  the  number  selected  is  less  than  P^ 
go  to  step  16,  otherwise  go  to  step  13. 

13.  Select  a  random  number.  If  the  number  selected  is  less  than  P3 
go  to  step  14,  otherwise  go  to  step  15. 

14.  Collect  statistics  for  the  duration  of  a  project  washout  and 
check  to  see  if  that  was  the  last  project  in  the  R&D  network 
(i.e.,  project  5).  If  it  is  project  number  5  then  terminate  the 
network,  otherwise  start  a  new  project  by  incrementing  X$FLAG 

by  one  and  go  to  step  3  (Blocks  25-28). 
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15.  Select  a  random  number.  If  the  number  selected  is  less  than  P^ 
go  to  step  5,  otherwise  go  to  step  8. 

16.  Read  the  mean  processing  time  and  modifier  for  stage  4  (Block  30) 
which  is  the  prototype  development  stage. 

17.  Start  stage  4  activity  (Block  31)  and  increment  time  by  one  day 
(Block  32)  until  the  duration  of  stage  4  activity  equals 
V$ACT.TIME  which  is  the  random  number  that  was  selected  from  an 
exponential  distribution  with  the  mean  and  modifier  assigned  in 
step  16. 

18.  Read  the  mean  processing  time  and  modifier  for  stage  5  (Block  34) 
which  is  the  solution  implementation  stage. 

19.  Start  stage  5  activity  (Block  35)  and  increment  time  by  one  day 
(Block  36)  until  the  duration  of  stage  5  activity  equals 
V$ACT.TIME  which  is  the  random  number  that  was  selected  from  an 
exponential  distribution  with  the  mean  and  modifier  assigned  in 
step  18. 

20.  Check  to  see  if  the  project  completed  was  the  last  project  in 
the  R&D  network  (i.e.,  project  5).  if  it  is  project  number  5 
then  collect  statistics  for  the  duration  of  the  5th  project 
successful  completion  and  terminate  the  network,  otherwise 
collect  statistics,  start  a  new  project  by  incrementing  X$FLAG 
by  one  and  go  to  step  3  (Blocks  38-42). 
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QMODL 1 , A 

GPSS  4.1  -ll/20-10:51-(U00) 


1 

2 

* 

Job 

3 

ORDER »FN 

l 

4 

ORDER iX 

6 

5 

ORDER* T 

40 

6 

SYS. STUDY 

Capacity 

b 

7 

RFP. PREP 

CAPACITY 

6 

e 

CON. PROP 

CAPACITY 

6 

9 

EVAL. AWU 

CAPACITY 

6 

10 

CON. WORK 

CAPACITY 

6 

11 

CON. EVAL 

CAPACITY 

6 

12 

♦ 

13 

*  NETWORK 

simulator: 

MULTIPLE  R&D  PROJfCT 

14 

* 

15 

PRO J. TIME 

TABLE 

ViPRO. TIME, 1400, 100, 10 

16 

T  ( 1 ) 

table 

ViPRO . T IME , 500 , 50 , 8 

17 

T(2) 

table 

ViPRO .TIME*  500 ,50,8 

18 

T  (31 

table 

ViPRO • T IME  *  500  *  50  »  8 

19 

T(4) 

table 

ViPRO. TIME, 1000,70.8 

20 

T(5) 

table 

ViPRO. TIME, 1000.70,8 

21 

T  (6  J 

table 

ViPRO. TIME, 1500,70,8 

22 

T(3l) 

table 

M$l* 100, 100, 10 

23 

T  ( 32 ) 

table 

Mil *100*100,10 

24 

T(33  J 

table 

Mil, 100* 100, 10 

25 

T  ( 34 ) 

table 

Mii,inu,ioo,io 

2b 

T  (35) 

tadle 

Mil* 100* 100, 10 

27 

T  ( 36) 

table 

Mil. 100, 100, 10 

28 

T  (21 1 

table 

ViPRO. TIME *500* 50, 8 

29 

T  (22) 

table 

ViPRO, T IME , 500 , 50  »  8 

30 

T  (23) 

table 

ViPRO .TIME *500* 50,8 

31 

T(24) 

table 

ViPRO. TIME, 1000,70,8 

32 

T(2d) 

table 

ViPRO. TIME, 1000.70,8 

33 

T(26) 

table 

ViPRO. TIME, 1500,70,8 

34 

FAIL. STUDY 

table 

PiPRO J .NO, 0*1, 7 

35 

FA1L.RFP 

table 

PiPROJ. NO. 0,1*7 

36 

FAIL. WORK 

table 

PiPRO J. NO *0*1,7 

37 

F AIL. PRO J 

table 

PiPROJ. 110,0, 1.7 

38 

TAB. VAR 

variable 

PiPROJ. N0+30 

39 

PHO.T1ME 

variable 

Cil-XSNET, START 

40 

S. POINT 

variable 

PiPROJ. NO+20 

41 

* 

42 

»  MATRIX  VAL(I» 

j)  stores  project  data  as  follows: 

43 

* 

44 

♦ 

Cul  l: 

PROJECT  NO. 

45 

♦ 

col  2: 

systems  study  activity  time*  mean 

46 

* 

COL  3: 

systems  study  activity  time,  modifier 

47 

* 

col  4: 

RFP  ACTIVITY  time*  MEAN 

48 

♦ 

col  5: 

RFP  activity  timf*  mooifiep 

49 

* 

COL  6: 

proposal  development  activity  time,  mean 

*50 

♦ 

COL  7: 

proposal  development  activity  time,  modifier 

51 

♦ 

col  o: 

proposal  evaluation  activity  time,  mean 

52 

* 

COL  9: 

proposal  evaluation  activity  time,  modifier 

53 

♦ 

col  10: 

contractor  effort  activity  time*  mean 

54 

* 

col  li : 

contractor  effort  activity  time,  modifier 

55 

* 

COL  12:  EVALUATION  ACTIVITY  TIME*  MEAN 

56 

♦ 

COL  13:  EVALUATION  ACTIVITY  TIME.  MODIFIER 

57 

♦ 

COL  14;  PROBABILITY  OF  ACCEPTABLE  INITIAL  DEFINITION 

58 

♦ 

COL  15:  PROBABILITY  OF  UNACCEPTABLE  PROPOSALS 

59 

* 

COL  16:  PROBABILITY  THAT  ADDITIONAL  EFFORT  IS  REQUIRED 

60 

* 

COL  17:  PROBABILITY  THAT  SOLUTION  IS  UNACCEPTABLE 

61 

♦ 

COL  18:  NUMBER  OF  DIRECT  PRECEDENT  PROJECTS 

62 

* 

COL  19:  NUMBER  OF  DIRECT  ANTECEDENT  PROJECTS 

63 

AU 

* 

$ 

COL  20-25:  PROJECT  NUMBERS  OF  ANTECEDENT  PROJECTS 

65 

MATRIX 

VAL16.25) 

66 

INITIAL 

VAL( 1* 1-11) ,1.84.1,32.1,58*0*24*0*360.0 

67 

INITIAL 

VALt 1,12-20) *63,1 ,925,005.014,065,0*1*4 

68 

INITIAL 

VAL(2. 1-11) ,2*92,1,31.1,68*0.35,0*348.0 

69 

INITIAL 

VAL(2, 12-21) ,52, 1 ,945, 020. 050,010,0,2.4,5 

70 

INITIAL 

VAL(3* 1-11) *3,95* 1*26. 1,53» 0,33* 0*380*0 

71 

INITIAL 

VAL (3* 12-20) ,61*1,999,070,038*070*0*1*5 

72 

INITIAL 

VAL(4* 1-11) *4,80*1*24,1,62,0*26,0*325*0 

73 

INITIAL 

VaL ( 4 . 12-20 ) *57,1,900,050*045*030*2*1*6 

74 

INITIAL 

VAL (5* 1-11) ,5,85, 1,20, 1,49,0,39*0*392*0 

75 

INITIAL 

VAL (5. 12-20) ,47.1,972,020,004,055*2*1*6 

76 

INITIAL 

VAL (6* 1-11) ,6,99*1*22,1,67*0,35*0*358*0 

77 

INITIAL 

VAL (6* 12-19) ,69,1,942,002,070*024,2*0 

78 

MATRIX 

FAlL.DATA(b*4) 

79 

* 

80 

♦ 

EXPONENTIAL  FUNCTION  F 1 1 )  USED  TO  MODIFY  ACTIVITY  TIMES 

81 

FN  ( 1 ) 

FUNCTION. EXP 

RF$2» 1.1 

82 

♦ 

83 

* 

Mb  PROJECT  NETWORK 

84 

1 

GENERATE 

0,1 

85 

2  proj. start  auvance 

86 

3 

SAVEX 

NET. START, Ctl 

87 

4 

SPLIT 

5 

88 

5  time.adj 

AUVANCE 

89 

6 

ASSIGN 

PROJ.NO.VSNQ.PROJ 

90 

MO. PRO J 

VARIABLE 

(NSTIME . ADJ-1 ) //6+1 

91 

7 

ADVANCE 

G0T0IPRED.1, INITIAL. I 

92 

8  PRED.l 

COMPARE 

MXSVAL (PSPROJ.NO* 18)  NE  0 

93 

9 

compare 

X$*PROJ.NO  E  MXSVAL (PSPROJ.NO, 18) 

94 

10 

ASSIGN 

POINT. START, VSS. POINT 

95 

11 

TABULATE 

♦POINT. START 

96 

* 

SYSTtM  STUDY 

97 

12  INITIAL. 

mark 

98 

13 

ASSIGN 

proj.set  *csi 

99 

14  STUDY. 1 

ASSIGN 

PROC. TIME, MXSVAL (PSPROJ.NO* 2) 

100 

15 

ASSIGN 

PROC . MOD , MXSVAL ( PSPRO J . MO  *  3 ) 

101 

16 

STORE 

SYS. STUDY  TIME(VSACT.TIME) 

102 

ACT. TIME 

VARIABLE 

PSPROC. TIME* (FN$*PROC. MOD) 

103 

17 

advance 

GOTO (MXSVAL (PSPROJ.NO. 14 > : STUDY .2  * RFP. 1 ) 

104 

18  STUDY. 2 

SaVEX 

RE  .STUDY , XSRE .STUDY  +  1 

105 

MSA VEX 

FAIL. DATA (PSPROJ.NO* 1) .MXSFAIL.DATA (PSPROJ 

106 

19  ♦NOfll+l 

107 

20 

AUVANCE 

GOTO ( STUDY • 1 ) 

103 

* 

RFP  PREPARATION 

109 

.  21  RFP.l 

ASSIGN 

PROC. TIME, MXSVAL (PSPROJ. NO, 4) 

110 

1  22 

ASSIGN 

PROC. MOD, MXSVAL (PSPROJ. NO, 5) 

111 

23 

STORE 

RFP. PREP  TIME(VSACT.TIME) 

55 


112 

* 

CONTRACTOR  PROPOSAL  PREPARATION 

113 

24 

ASSIGN 

proc .time*  mxsval (psproj . mo*  6) 

114 

25 

Si  ORE 

CON. PROP  TIME(P$PROC.TImE) 

115 

* 

PROPOSAL  EVALUATION  AND  AWARD 

116 

26 

ASSIGN 

Proc . t ime  * mxsval (Psproj.no  •  8) 

117 

27 

STORE 

EVAL.AWD  TIME(PSPROC.TImF) 

118 

28 

ADVANCE 

GOTO (MXSVAL (PSPROJ. no, 15) : CON. 1 *RFP .2 > 

119 

29  RFP.2 

SAVEX 

RE.RFP,X$RE.RFP*1 

120 

MsAVEX 

FAIL. DAT A (PSPROJ. NO* 2) *mXSFAIL. DATA (PSPROJ 

121 

30  *NO*2)+l 

122 

31 

ADVANCE 

GOTO ( RFP . 1 ) 

123 

* 

CONTRACTOR  ACTIVITY 

124 

32  CON* 1 

ASSIGN 

PROC . T I  ME  *MXtVAL ( PSPROJ. NO* 10) 

125 

33 

STORE 

CON. WORK  TIME(PSPROC.TImE) 

126 

* 

CONTRACT  evaluation 

127 

34 

ASSIGN 

proc.time*mx*val(p$proj.no* 12) 

128 

35 

ASSIGN 

PROC. MOD* MXSVAL (PSPROJ. NO* 13) 

129 

36 

STORE 

CON.EVAL  TIME(VSACT.TIME) 

130 

37 

ADVANCE 

GOTO (MXSVAL (PSPROJ. NO, 16) : EVAL. 1 *C0N.2 ) 

131 

38  CON. 2 

SAVEX 

RE.  WORK *X$RE* WORK* 1 

132 

MSAVEX 

FAIL.DAT A (PSPROJ.NO* 3) * MXSFAIL.DAT A (PSPROJ 

133 

39  *110*  3 )  +1 

134 

40 

ADVANCE 

GOTO (CON. 1 ) 

135 

41  EVAL.l 

ADVANCE 

G0T0(MXSVAL(PSPR0J.M0*17) IEVAL.3*EVAL.2) 

136 

42  EVAL.2 

SAVEX 

PROJ. FAIL ,XSPROJ. FAIL* 1 

137 

MSAVEX 

FAIL. DATA (PSPROJ.NO* 4) *MXSFAIL. DATA (PSPROJ 

138 

43  *N0  *  4 ) +1 

139 

44 

ADVANCE 

GOTO (STUDY. D 

140 

45  EVAL.3 

ADVANCE 

GOTO (NEXT. PROJ* LAST. PROJ) 

141 

46  NEXT. PRO. j 

COMPARE 

MXSVAL (PSPROJ.NO* 19)  NE  0 

142 

47 

ASSIGN 

NO. PROJS* MXSVAL (PSPROJ.NO, 19) 

143 

48 

ASSIGN 

COL. NO* 19 

144 

49  LOOP. START 

ASSIGN 

COL. NO* PSCOL.NO* 1 

145 

50 

ASSIGN 

PRO J. NEXT  *  MXSVAL ( PSPROJ . NO  *  PSCOL.NO ) 

146 

51 

SAVEX 

♦PROJ. NEXT *X$*PR0J.NEXT+1 

147 

52 

LOOP 

NO. PROJS*LOOP. START 

148 

53 

TAEULATE 

♦PROJ. NO 

149 

54 

ASSIGN 

PROJ. DUR.VSTAB. VAR 

150 

55 

ASSIGN 

PROJ. END, CS1 

151 

56 

TABULATE 

♦PROJ.DUR 

152 

57 

terminate 

153 

58  LAST ,PROJ 

tabulate 

PROJ. TIME 

154 

59 

assign 

NO. PROJS *6 

155 

60  START. LOOP 

SAVEX 

♦  NO. PROJS*  0 

156 

61 

LOOP 

NO. PROJS* ST ART. LOOP 

157 

62 

SPLIT 

1, PROJ. START 

158 

63 

TABULATE 

♦PROJ. NO 

159 

64 

assign 

PROJ, DUR*VSTAR. VAR 

160 

65 

assign 

PROJ. END* C$1 

161 

66 

TABULATE 

♦PROJ.DUR 

162 

67  TERM. CUT 

terminate 

163 

68 

GENERATE 

0*1 

164, 

165 

69 

COMPARE 

NSTERM.CNT  E  100 

,  70  COMP. 2 

ASSIGN 

PRO J. NO* PSPROJ. NO* l 

166 

*  71 

ASSIGN 

POINT. START, VSS. POINT 

167 

72 

ASSIGN 

PROJ. DUR,VSTAB. VAR 

168 

HELP 

PSPROJ. NO* TRS*P0INT. START *TDS*P0INT. START, 

56 


169 

73 

+HS*PROJ.OUK. 

tos*proj.our»tbs*proj.no.tds*proj.no 

170 

74 

ADVANCE 

GOTO ( COMP. 1, COMP. 2) 

171 

75 

COMP. 1 

compare 

PSPROJ.MO  E  6 

172 

76 

ASSIGN 

PROJ. NO. 0 

173 

77 

COMP. 4 

ASSIGN 

PROJ. MO  *  PSPROJ.NO* 1 

174 

HELP 

P$PROJ.NO*MXSFAIL .DATA (PSPROJ.NO* 1 ) .MXSFAIL 

175 

♦ .DATA (PSPROJ 

. NO*  2 ) »MX$FAIL 

.DATA (PSPROJ.NO. 3) . MXSFAIL .DATA (PSPROJ.NO . 4 ) , 

176 

78 

♦ » *  1 

177 

79 

ADVANCE 

GOTO (COMP. 3. COMP. 4) 

178 

80 

COMP. 3 

COMPARE 

PSPROJ.NO  E  6 

179 

81 

TERM1NATE*R 

180 

START 

1 

storages: 

SyS. study  kfp.prep  con. prop  eval.awd  con. work 

coh.eval 


parameter*,: 

proj.no  point. start  proj.set  proc.time  proc.mod 

NO.PROJS  col.no  proj.next  proj.dur  proj.end 


tables: 

PROJ.TIME  FAIL. STUDY  FAIL.RFP  FAIL. WORK  FAIL.PROJ 


Savexs: 

net. START  re. STUDY  RE.RFP  RE. WORK  PROJ.FAIL 


MATRIX  SAVEXS: 

VaL  FAIL. data 


VARIABLES: 

TAO.VAR  PRO. TIME  S, POINT  NO.PROJ  ACT. TIME 


BLOCKS: 

2  PROj. START 

12  initial. 

21  RFP.l 
38  CON. 2 
45  EVAU.3 
58  LASr. PROJ 
70  COMp.2 
80  COM^.3 


HUMBER  OF  TRANSACTIONS  ALLOWED:  2487 


5  TIME. ADJ 
14  STUDY. 1 
29  RFP.2 
41  tVAL.l 
46  NEXT. PROJ 
60  START. LOOP 
75  COMP . 1 


8  PREO.l 
18  STUDY. 2 
32  CON. 1 
42  E VAL . 2 
49  LOOP. START 
67  TERM.CNT 
77  COMP. 4 
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A  THREAT  ALLOCATION  MODEL  FOR  TACTICAL  WARFARE 
INTRODUCTION 

One  of  the  key  tasks  facing  the  military  planner  in  specifying  defense  mission 
requirements  is  assessing  the  nature  of  the  threat  which  must  be  countered.  In 
tactical  situations,  a  significant  component  of  the  threat  may  be  represented  by 
the  opposition's  tactical  ballistic  missile  stocks.  Thus,  a  question  of  extreme 
importance  to  the  tactical  defense  system  planner  is  how  the  opposition  might 
target  a  given  force  of  tactical  ballistic  missiles  against  a  specific  set  of 
military  targets  in  such  a  way  as  to  achieve  desired  military  objectives. 

The  research  described  in  this  paper  has  as  its  major  focus  the  development  of 
a  computer-based  mathematical  threat  allocation  model.  The  research  is  presented 
in  four  parts.  The  first  part  oetails  the  basic  threat  allocation  decision,  iden¬ 
tifying  and  describing  important  elements  of  the  decision.  The  mathematical  and 
computer  models  developed  to  represent  the  threat  allocation  decision  are  presented 
in  the  second  part  of  the  paper.  Examples  of  the  different  types  of  analysis  which 
are  possible  with  the  model  are  described  in  the  third  part.  The  final  part  of  the 
paper  presents  conclusions  and  identifies  areas  for  future  research. 

THE  THREAT  ALLOCATION  DECISION 

A  graphic  representation  of  the  mission  analysis  phase  of  tactical  ballistic 
missile  defense  planning  is  shown  in  Figure  1.  In  accomplishing  the  mission  ana¬ 
lysis  task,  the  analyst  must  specify  mission  requirements  necessary  to  achieve 
specified  military  objectives  for  a  given  set  of  military  assets  for  various 
assumed  TBM  threats.  In  order  to  make  such  a  specification,  the  analyst  must 
first  determine  how  a  specified  threat  would  likely  be  targeted  against  the  assets 
and  what  the  resulting  damage  would  be.  From  Figure  1  it  may  be  seen  that  the 
inputs  necessary  to  make  threat  allocation  and  damage  assessment  determinations 
are:  the  threat  definition,  the  asset  structure,  damage  assessment,  and 


rements  Flow  Diagram 
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attack/defense  scenarios.  Each  of  these  inputs  will  now  be  described  as  it 
relates  to  the  allocation  decision. 

Threat  Definition 

A  TBM  threat  may  be  definea  by  specifying  several  key  characteristics  of  the 
threat:  (1)  the  types  of  TBM's  (weapons  systems)  composing  the  threat,  (2)  the 
types  of  warheads  involved,  (3)  number  and  location  of  launchers,  (4)  number  of 
boosters,  (5)  ranges,  (6)  reload  time  requirements,  and  (7)  availability/ 
reliability  estimates.  An  example  threat  definition  based  on  hypothetical  data 
is  shown  in  Table  1.  The  threat  depicted  is  composed  of  four  weapons  systems 
identified  as  RED-1  thru  RED-4.  The  numbers  of  boosters  and  ranges  (specified 
in  terms  of  geographic  zones)  are  given  for  each  weapons  system.  Availability/ 
reliability  estimates  are  also  specified  for  each  weapons  system.  For  purposes 
of  illustration,  the  number  of  launchers  is  assumed  to  be  equal  to  the  number 
of  boosters,  hence  reload  times  need  not  be  considered. 

Asset  Structure 

The  asset  structure  against  which  the  TBM  threat  is  targeted  is  defined  in 
terms  of  four  characteristics:  (1)  types  of  assets  threatened,  (2)  number  and 
geographic  location  (by  zone)  of  each  asset,  (3)  value  of  each  asset,  and 
(4)  type  of  target  pattern  represented  by  each  asset.  An  example  asset  structure 
based  on  hypothetical  data  is  shown  in  Table  2.  In  the  example  there  are  four 
categories  of  assets  designated  as  BLUE-1  thru  BLUE-4.  These  categories  might 
represent  airbases,  missile  sites,  supply  points,  command  centers  or  other  assets 
having  military  significance.  Each  type  of  asset  is  assigned  a  value  from  0  to 
1000  which  reflects  the  military  importance  of  that  asset  type  relative  to  other 
asset  types.  Obviously,  these  values  are  subjectively  determined  and  will  vary 
depending  on  military  objectives  to  be  achieved.  Procedures  for  assessing  the 
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impact  of  alternative  value  schemes  are  discussed  later.  Assets  are 
characterized  as  either  simple  (S)  or  complex  (C)  depending  on  whether  one  or 
more  aimpoints  must  be  targeted  in  order  to  disable  or  destroy  the  asset. 


Damage  Assessment 

The  probability  of  destroying  or  neutralizing  an  asset  by  targeting  a 
single  booster  on  the  asset  is  referred  to  as  a  single  shot  kill  probability 
(Pssi^)*  Table  3  gives  hypothetical  values  for  the  assumed  threat  and  asset 
structure  examples  described  in  previous  sections.  The  values  for  an  actual 
application  are  obtained  from  probability  equations  or  simulation  analysis  and 
depend  on  specified  damage  criteria  required  for  kill,  target  position  and 
location  error,  reentry  vehicle  lethality,  and  delivery  accuracy. 


Attack/Defense  Scenarios 

In  modeling  the  threat  allocation  decision,  it  is  necessary  to  incorporate 
the  capability  to  treat  a  variety  of  military  objectives  for  the  threatening 

r 

force  as  the  objective  set  is  a  major  determinant  in  the  allocation  decision. 

The  allocation  model  should  be  flexible  enough  to  permit  a  broad  range  of 
potential  objectives  represented  by  specific  attack  scenarios.  Defense  scenarios 
which  are  inputs  to  the  allocation  decision  derive  from  the  military  objectives 
of  the  threatened  force  and  from  defensive  tactics  of  interest.  Specific  attack 
and  defense  scenarios  which  may  be  addressed  are  described  later  in  the  analysis 
section  of  the  paper. 


In  the  parlance  of  decision  modeling,  the  threat  definition,  the  asset 
structure,  damage  assessment,  and  attack  scenarios  are  uncontrollable  factors, 
that  is,  the  decision-maker  accepts  them  as  givens  even  though  the  values  of 
these  factors  may  be  varied  for  assessment  purposes.  Defense  scenarios  are  the 
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decision-maker's  choice  or  controllable  factors.  The  decision-maker  is 
interested  in  discovering  how  the  assumed  threat  will  be  targeted  over  the  assets 
for  attack/defense  scenarios  of  interest.  This  is  the  essence  of  the  threat 
allocation  decision. 

DECISION  FORMULATION 

The  threat  allocation  decision  described  in  the  preceding  section  can  be 
formulated  in  a  relatively  straightforward  manner  as  a  resource  allocation  deci¬ 
sion  and  treated  with  conventional  resource  allocation  techniques.  The 
mathematical  representation  of  the  threat  allocation  decision  will  now  be 
described  followed  by  a  discussion  of  the  computer  routine  that  was  developed 
for  obtaining  allocation  schemes. 


A^  =  the  number  of  type  i  boosters  available. 

j  =  the  number  of  asset  types,  j=l,  2,  .  .  .,  n. 
X..  =  the  number  of  type  i  boosters  targeted  against 

*  J 


each  asset  of  type  j. 
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F( X . . )  =  the  expected  value  of  type  j  assets 

'  J 

destroyed  by  type  i  TBM's. 

The  optimization  criterion  used  in  making  the  TBM  allocations  is  the 
incremental  value  AF(X.. )  of  type  j  assets  destroyed  by  an  additional  booster 

*  J 

of  type  i.  For  simple  assets,  those  requiring  a  single  aimpoint,  the 


optimization  criterion  is 


4F<V  ■  Vj 


Where 


P.  .  =  the  probability  of  killing  a  type  j  asset 
*  0 

with  a  single  booster  of  type  i. 

V.  =  the  value  of  type  j  assets. 

J 

For  complex  assets,  those  having  physical  characteristics  which  dictate  that 
multiple  aimpoints  be  targeted  to  neutralize  or  destroy  the  asset,  the 
optimization  criterion  is 


m  r  X../M“tt 

4F<V  s  Vj  0 


Where 


M  =  the  number  of  aimpoints  which  must  be 


targeted. 

Equations  1  and  2  constitute  a  non-linear  integer  programming  model;  the 
objective  function  for  simple  assets  is  a  convex  function  which  greatly  simpli¬ 
fies  the  task  of  obtaining  an  optimum  solution.  The  procedure  used  is  a 
modification  of  the  "greedy"  algorithm  which  allocates  TBM's  to  assets  one  TBM 
at  a  time  maximizing  the  incremental  value  criterion  given  in  equation  3  for 
each  allocation.  For  complex  assets,  the  objective  is  not  convex,  however,  a 
heuristic  assignment  algorithm  was  developed  which  essentially  computes  the 
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optimum  allocation  of  IBM's  to  complex  assets  by  sequential  enumeration.  Then, 
if  no  better  allocation  to  simple  assets  is  possible,  the  TBM's  are  allocated 
to  complex  assets. 

The  Computer  Model 

An  interactive  FORTRAN  program  was  developed  to  perform  computations 
necessary  to  generate  optimum  threat  allocation  schemes.  The  program  includes 
approximately  650  lines  of  code;  execution  requires  about  70  core  blocks  of 
memory  and  about  30  seconds  of  CPU  time  on  a  UNIVAC  1100/60  time  sharing 
system.  Current  capacity  of  the  program  is  8  TBM  types,  300  asset  types,  and 
3  geographic  zones.  These  values  may  be  increased  to  some  extent  by  judicious 
alteration  of  the  input  data;  however,  existing  capacity  is  probably  adequate 
to  accommodate  most  situations  which  might  arise. 

Decision  data  required  as  input  is  entered  either  by  means  of  a  permanent 
data  file  or  interactively.  Much  of  the  decision  data  is  changed  only  infre¬ 
quently  during  analysis,  hence,  it  is  convenient  to  input  and  store  this  data 
in  a  permanent  file.  Some  of  the  data  is  changed  routinely  during  analysis, 
so  the  program  was  developed  to  permit  interactive  input.  Required  inputs  are: 

Permanent  Data  File 

•  Number  of  TBM  types 

•  Number  of  asset  types 

•  Asset  values 

•  Asset  locations  (number  in  each  zone) 

•  Kill  probabilities 

Interactive  Inputs 

•  Availability/Reliability  factors 

•  Number  of  TBM's 


% 

% 


! 


r 
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Two  types  of  information  are  available  as  output  from  the  threat  allocation 
program:  booster-asset  allocations  and  aggregate  damage  summaries.  Booster- 
asset  allocation  information  is  provided  in  a  detailed  report  for  each  asset 
type  reflecting  the  number  of  boosters  of  each  weapons  system  allocated  to  each 
asset  by  geographic  zone.  These  reports  also  reflect  damage  estimates  resulting 
from  the  given  allocations.  An  aggregate  damage  summary  shows  damage  assessments 
by  asset  type  by  zone  and  total  damage  and  fraction  of  asset  value  surviving  by 
asset  type.  Examples  of  program  output  are  shown  in  Figure  2  and  3. 

ANALYSIS 

The  computer-based  allocation  procedure  described  in  the  preceding  section 
offers  the  defense  system  planner  an  extremely  flexible  tool  for  analysis.  A 
wide  variety  of  tactical  situations  can  be  analyzed  with  relative  ease.  To 
illustrate  how  the  model  may  be  used  in  analysis,  three  major  types  of  analysis 
will  be  described  and  illustrated  with  the  threat/asset  structure  example 
presented  earlier. 

r 

Attack  Scenarios 

One  question  frequently  asked  by  defense  planners  relating  to  various  attack 
scenarios  is,  what  is  the  impact  of  changing  the  TBM  stock  available  to  the 
opposing  force?  An  analysis  of  the  impact  of  the  number  of  boosters  on  asset 
damage  is  accomplished  by  generating  a  series  of  allocations  varying  che  booster 
quantities.  Figure  4  shows  such  an  analysis  in  which  allocations  were  made  with 
20%,  40%,  60%,  80%,  100%,  and  120%  of  the  booster  quantities  given  in  Table  1. 
Thus  Threat  Level  in  percent  of  boosters  available  is  the  independent  variable 
in  Figure  4,  while  Surviving  Fraction  of  Initial  Value  of  the  assets  is  the 
dependent  variable.  The  figure  shows  that  for  the  example  situation  being 
considered  if  20%  of  the  stock  of  boosters  is  targeted  against  the  assets, 


I  *  .  ’  v1  ' 


Figure  3.  Aggregate  Damage  Summary 
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approximately  87  percent  of  the  value  of  the  assets  would  survive;  whereas  if 
120%  of  the  booster  stock  is  targeted,  only  50%  of  the  value  of  assets  would 
survive.  Detailed  booster-asset  allocation  schemes  and  damage  summaries  for 
the  individual  runs  depicted  in  Figure  4  are  available  from  the  computer  reports. 


Parametric  Analysis 

A  variety  of  "what  if"  questions  may  be  investigated  by  performing 
parametric  analysis  on  individual  characteristics  of  the  threat/asset  structure 
system.  Figures  5,  6,  and  7  show  the  results  of  parametric  analysis  on 
values,  asset  values,  and  reliability  factors  respectively;  each  of  these 
parametric  analyses  is  done  in  the  context  of  the  threat  level’ variation 


described  in  the  preceding  paragraph.  Figure  5  indicates  that  at  the  120% 
threat  level,  a  20%  increase  in  P<.<jK  values  would  cause  a  10%  decrease  in  the 
value  of  assets  surviving.  Figure  6  shows  the  impact  of  changing  the  value 
assigned  to  each  of  the  asset  types.  The  curve  labeled  "Uniform  Values"  was 
generated  by  assigning  a  value  of  200  to  each  of  the  asset  types.  The  figure 
suggests  that  the  allocation  model  is  relatively  insensitive  to  asset  values. 
Figure  7  presents  results  of  parametric  changes  on  the  rel i al?i  1  i ty/ava i lability 
characteristic  of  TBM  weapons  systems. 


Defense  Scenarios 

The  model  is  flexible  enough  to  permit  analysis  of  a  variety  of  defense 
scenarios.  Figure  8  presents  results  which  would  be  expected  from  defending  the 
assets  against  the  TBM  threat.  The  curve  labeled  "Uniform  Defense"  represents  a 
defense  system  which  would  uniformly  protect  all  assets;  the  curve  depicts  a 
system  having  60  percent  efficiency,  that  is,  only  40  percent  of  targeted 
boosters  would  penetrate  the  defense.  The  curve  labeled  "Preferential  Defense" 
illustrates  the  impact  of  protecting  "preferred"  assets  as  opposed  to  uniformly 
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defending  all  assets.  This  curve  was  generated  by  reducing  the  P^  values  for 
the  BLUE-2  asset  by  50%,  approximating  the  effect  of  deploying  a  defense  system 
for  this  asset. 

The  examples  presented  in  this  section  by  no  means  exhaust  the  analysis 
potential  of  the  allocation  model;  they  do  serve  to  illustrate  the  range  and 
diversity  of  issues  which  can  be  investigated. 

CONCLUSIONS 

The  threat  allocation  model  described  in  this  paper  gives  the  defense  system 
planner  an  extremely  flexible  tool  for  answering  the  kinds  of  questions  which 
arise  in  tactical  planning.  Data  requirements  of  the  model  are  neither  com¬ 
plicated  nor  elaborate;  in  fact,  most  of  the  input  data  required  would  normally 
be  available  to  a  system  planner.  The  model  is  relatively  simple  to  use  and 
the  outputs  are  largely  self-explanatory. 

Several  revisions  of  the  model  have  been  accomplished  in  attempting  to 
incorporate  as  much  detail  and  accuracy  as  possible  and  practical.  There  are 
a  few  enhancements  and  extensions  which  could  further  improve  the  model's 
usefulness.  One  possibility  for  enhancing  the  model  relates  to  asset  valuation; 
currently  assets  are  valued  by  subjectively  assigning  values  from  0  to  1000  to 
each  asset  type.  Presumably,  the  values  assigned  reflect  the  military  worth 
of  the  asset  types.  This  subjective  valuation  approach  is  the  most  obvious 
limitation  of  the  model;  more  objective  methods  of  valuing  assets  would  improve 
the  credibility  of  the  model.  With  respect  to  model  extensions,  the  model  cur¬ 
rently  incudes  only  limited  capability  for  assessing  the  impacts  of  threat  system 
logistics,  i.e.,  stockpile  quantities,  launcher  capacities,  and  resupply  and 
reload  times.  Clearly,  the  model's  usefulness  could  be  enhanced  by  incorporating 
a  submodel  which  described  relevant  logistics  considerations. 
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